larrybotha

Resolved!

Hi there, My company, Fixate, has been building and supporting ProcessWire sites for a number of years now. I've recently accepted an offer for a position at another company, and as the last dev on the team (the team is now primarily UI/UX), we need to find someone who can assist with client requests. We have clients in Canada, Zambia, and South Africa, so we're comfortable with any timezone you may be in. The projects predominantly have this setup: Dockerised services for quick setup Gulp to automate: builds and file revisioning SSH deployments backups / restorations Some of our client's sites: blu-line.co.za biocarbonpartners.com knowledgehub.southernafricatrust.org We're looking for someone to work directly with our clients when they need assistance. Feel free to contact me at larry U+0040 fixate.it Thanks! Larry

@onjegolders ye, that's a far superior way of working with uploaded assets. I still need to take a look at S3 integration with ProcessWire, but that would alleviate a lot of headaches.

@onjegolders ye that's a bit of a pain. At Fixate we generally use placeholders until real content is added. Once real content is added, if someone needs the content for anything specific (usually the devs don't need all assets to work on the site) we'll Slack each other the assets. Once a site is on a staging environment it gets easier to manage, as final content is usually added there. We use rsync to sync remote assets to local folders, and sync site files to the remote using Gulp: https://github.com/fixate/generator-fixate-pw/blob/master/app/templates/gulp/tasks/rsync.js I'd be interested to hear how others handle it, but yup - don't commit assets or generated files (*.css, *.js, minified images, etc) to your repo - your repo should contain only dev and working files; a build process should be responsible for generating production files. Clean repos, and clean commit histories

Perhaps working solo and on only one machine would be ok for not committing database versions, but working with multiple devs would make db updates a nightmare if they weren't committed to a repo. Working from a single remote database is painfully slow, and as soon as you have no internet, your work stops there and then. At Fixate we've always versioned our db's for ProcessWire sites. Adding db exports to a repo is not ideal, but in terms of pragmatic workflow it's the fastest way to keep a project moving efficiently. The alternative would require a manifest or generator that would check if the correct fields are present on a database, and programmatically insert them (like Rails migrations). This would be the best way to go, as you're versioning your schema, as opposed to your data, but in terms of flexibility of what your admin looks like, you're going to have to manage enormous schemas for each template and field if you're to ensure the best UX in the admin for your clients. We've automated MySQL exports and imports with Gulp: https://github.com/fixate/generator-fixate-pw/blob/master/app/templates/gulp/tasks/mysql.js

@Nico Smit I took a look last night at 3.x with the MVC framework - I ran into a few issues where previously global ProcessWire functions weren't available, such as `wire` and `wireEncodeJSON` in `traits/search.php` and `controllers/javascript.php` (there'll be a couple other files, such as `traits/forms.php`, but I haven't yet scoured all the files), but the issue was remedied by adding the ProcessWire namespace to those files, and using the namespace to access the functions: <?php # traits/search.php use ProcessWire as PW; ... # changed from wire(...) to: PW\wire(...); I didn't have any issues with `Error: Class 'Environment' not found`. I did an install using our generator. UPDATE 06/11/2016: Just released 0.5.9 which adds fixes for the global `wire` calls in the boilerplate: https://github.com/fixate/pw-mvc-boilerplate/releases/tag/0.5.9

@Nico Smit our last PW project was released when 3.x was not yet stable, so we haven't yet toyed with the latest stable branch of PW. We'll be starting one or two new PW sites in the coming months, but with our current backlog I'm not sure we'll be getting there any time soon! In my spare time I'm building a project for our company on PW which will be starting in the next couple weeks, so I'll have to ascertain how quickly I can resolve those issues. If it's not too much trouble (I think it may come down to refactoring how our classes are instantiated / namespaced) I'll update the boilerplate then, but with our deadlines I may be forced to carry on with 2.x until I do get the time. @Nico Smit if you can open an issue, or even make a pull request it would be much appreciated!

To supplement @John the Painter's answer: 1. Update InputfieldMapMarker.module to get your API key however you're managing it: public function init() { $apikey = // get my api key $script_path = ($this->config->https ? 'https' : 'http') . "://maps.googleapis.com/maps/api/js?key={$apikey}"; $this->config->scripts->add($script_path); return parent::init(); } 2. Enable 'Google Maps Geocoding API' in your Google API Console for your site's API key: https://console.developers.google.com/apis/api/geocoding_backend/overview You may need to enable whichever other individual APIs (places, geolocation, etc.) from Google's API library for the client side if you use the same API key: https://console.developers.google.com/apis/library Updating the MapMarker module will remove these changes if this file is affected by the update.

We've made a lot of progress on our generator. We're now using Gulp to automate everything, but still, it ties in strongly with our PW Boilerplate. You'll likely find a lot of useful things in our generator that you can take over. Some useful things: automatically downloads the latest PW automatically gets a few PW Modules we use in all projectsMarkupSimpleNavigation ProcessRedirects MarkupSitemapXML install npm and all the dependencies in the Gulpfile initialises bower The generated Gulpfile has a bunch of useful utilities: browsersync sass and coffee compilation asset revisioning for production cache busting (like fingerprinting in Rails apps) rsync utilities Instead of bash scripts being run, we've opted for a small Node app for better cross OS support. Feel free to fork it, and add and remove as you see fit.

thanks @WinnieB Yeoman's great for automating the dirty work and getting right to business. @boundaryfunctions great to hear it may be of use to you! It's very much based on Rails, and our new manifest feature is reminiscent of Sprockets / Asset Pipeline (but way faster thanks to Node and Gulp). Make sure to check out the wiki on the repo on Github - it's a little rough around the edges, but it should get you going a bit faster.

We've now added cache busting for all assets in our boileplate. This means that in production, if an asset has been added to a manifest in the assets/ folder, your site will now serve an MD5'd version of the file. i.e. style.css -> style-18925h5bsdfsdfn.css No worries about appending query strings or force refreshing to get the latest asset, it's all done for you. Use of the manifest is optional. If an asset is not being rev'd in the manifest, it will be served with the filename you provide. e.g.: <!-- if this asset is not in the manifest, it will be served as assets/img/logo.svg --> <link rel="logo" type="image/svg" href="http://<?= $config->httpHost . $this->assets('img/logo.svg') ?>"/> <!-- if this asset IS in the manifest, in production it will be served as assets/css/style-9n183he.css --> <link rel="stylesheet" type="text/css" href="<?= $this->assets('css/style.css') ?>" > For an asset to be eligible for rev'ing, it must be accessed through the assets helper in views / templates: $this->assets('path/to/my/asset.ext') This is used best in conjunction with some sort of task automation, for which we have a Yeoman generator which generates a project with a Gulpfile that handles all the rev'ing of assets without any additional work for you: https://github.com/fixate/generator-fixate-pw (and more specifically, the gulpfile: https://github.com/fixate/generator-fixate-pw/blob/master/app/templates/_gulpfile.coffee) To create the manifest, you can run the following from the command line: $ gulp build You're now ready to deploy with your cache busted assets. Assets that are being rev'd by Gulp are css, js, images, and fonts (even handles rewriting paths in your css). Happy cache busting!

A quick update: we've added a manifest for cache busting of assets via our generator and boilerplate. Assets in development are served as is, production assets are all MD5'd with references stored in a manfiest in /assets/rev-manifest.json If the manifest doesn't store a reference to an asset obtained via $this->assets('path/to/asset.ext') then it will simply serve the asset as specified in that helper. This means the manifest is completely optional. The manifest is generated via gulp tasks generated via our generator. The default gulp task will watch assets relevant to being revisioned, and keep the manifest updated as you work. ProcessWire Boilerplate: https://github.com/fixate/pw-mvc-boilerplate ProcessWire Generator: https://github.com/fixate/generator-fixate-pw

Glad to hear it's worked out nicely for you, @spoetnik! Thanks for opening that issue on Github - if you come across anything else, please open an issue or feel free to send through a pull request

Hi Mackski! The page-specific method is being called by the MVC framework, not by PW itself! Let's say you have a page with a name of /i-really-enjoy-carpeting using a template called 'carpeting'. Inside carpeting_controller.php you could then have the following: # carpeting_controller.php.php class CarpetingController extends ApplicationController { function page_i_really_enjoy_carpeting() { return $this->render(); } function index() { ... } } What happens before a page is rendered is the call() method inside core/controller.php checks to see if there exists a method matching the snake-cased version of the current page name, prepended by 'page_'. If so, it will use that method instead of index() in the controller, allowing you to set variables and use templates for that page only. i.e. if the current page's name is i-really-enjoy-carpeting, and a page_i_really_enjoy_carpeting() method exists in the controller, use that method to process logic for that page.

You can render templates from wherever you like - by default render() will look inside views/, but you can set a relative path from there: // MyController.php class MyController extends ApplicationController { ... function index() { ... // use views/dialogs/my_template.html.php return $this->render('dialogs/my_template', array(...)); } } will look inside views/dialogs/ Did I understand your question correctly? ---------------------------------------------- WRT api_controller.php, my knowledge of ajax is pretty slim (I didn't write any of the API stuff, so I may be wrong here), but what appears to happen is when a request comes in from your JS, the boilerplate will look at controllers/api/my_controller.php instead of controllers/my_controller.php. Inside controllers/api/my_controller.php you will extend ApiController, instead of Controller. The call() method in the ApiController class, in contrast to the Controller class', looks for a method that matches an HTTP verb you would need to define in your controller (PUT, PATCH, DELETE, and UPDATE don't seem to be supported - perhaps because ProcessWire only supports GET and POST), and handles it accordingly. The ApiController class has its own partial() method to generate markup inside controllers. The return value of your method is then handed back to your JS. So, in a nutshell, you should be able to create a new controller as follows: <?php /** * MyController - API Controller */ class MyController extends ApiController { ... // GET verb specified in AJAX request function get() { ... $html = ''; // use views/partials/dialogs/my_dialog.html.php $html .= $this->partial("dialogs/my_dialog", array(...)); // return results of request to js return array( 'html' => $html ); } } Additionally, there's a function, render_js_data(), in javascript.php which will retrieve the page's path and template as a window object in a script tag for easy access in your javascript. You can simply add it to scripts.html.php: // scripts.html.php ... <?= $this->render_js_data() ?> <?= $this->render_scripts() ?> and in your js then use: // main.js if (this.processWire.template === 'my_template') { // do something } I hope I've made sense!